Maybe add a comment inside the empty if, something like "Not sending WebXDC updates in the first part of resent WebXDC".

Removed resend at all. Now updates are sent together with the instance on resending it.
EDIT: We can account also the instance size to respect the limit more accurately, but if so then better to do this in a separate commit.

@link2xt If we want to account the instance size too, then it's a question whether we should do that only for resent instances, or initially too. And if we want to account the instance size only for resent instances, maybe better not to apply the size limit to initially sent instances at all to avoid unwanted message splitting and problems when the second message (containing initial updates) isn't delivered

What does "parallel running" mean here?

I am looking at SMTP loop, there send_smtp_messages flushes status updates, adding them at the end of SMTP queue, and then sends all queued messages.

Saying "to make Context::flush_status_updates() send the updates again." is easier to read unless I am missing something.

Tried to improve the comment. It's needed because it's not obvious why first_serial - 1 is here

The comment says that the value must not be used as a status update ID, but there is actually nothing preventing it from being used as status update ID. If .next() returns this status ID, it gets used. Seems the only reason for having MAX not equal to u32::MAX is to prevent render_webxdc_status_update_object failing because it calls next() on the last argument.

If there is actually no protection, then why not make next() use saturating_add and use u32::MAX for maximum? Then next() does not need to return Result. I tried, no tests failed:

index 55ba6dd70..dc8bb98e0 100644
--- a/src/webxdc.rs
+++ b/src/webxdc.rs
@@ -126,7 +126,7 @@ pub fn new(id: u32) -> StatusUpdateSerial {
     /// Minimum value.
     pub const MIN: Self = Self(1);
     /// Maximum value.
-    pub const MAX: Self = Self(u32::MAX - 1);
+    pub const MAX: Self = Self(u32::MAX);

     /// Gets StatusUpdateSerial as untyped integer.
     /// Avoid using this outside ffi.
@@ -136,12 +136,8 @@ pub fn to_u32(self) -> u32 {

     /// Returns next [StatusUpdateSerial].
     /// May `MAX + 1`, but this value mustn't be used as a status update id.
-    pub fn next(self) -> Result<StatusUpdateSerial> {
-        Ok(StatusUpdateSerial(
-            self.0
-                .checked_add(1)
-                .context("StatusUpdateSerial overflow")?,
-        ))
+    pub fn next(self) -> StatusUpdateSerial {
+        StatusUpdateSerial(self.0.saturating_add(1))
     }
 }

@@ -778,7 +774,7 @@ pub(crate) async fn render_webxdc_status_update_object(
                         }
                         json.push_str(&update_item);
                     }
-                    Ok((json, last.next()?))
+                    Ok((json, last.next()))
                 },
             )
             .await?;
@@ -1926,7 +1922,7 @@ async fn test_pop_status_update() -> Result<()> {
         let mut instances_checked = 0;
         for i in 0..3 {
             let (instance, min_ser, max_ser, descr) = t.smtp_status_update_get().await?.unwrap();
-            t.smtp_status_update_pop_serials(instance, min_ser, max_ser.next()?)
+            t.smtp_status_update_pop_serials(instance, min_ser, max_ser.next())
                 .await?;
             let min_ser: u32 = min_ser.try_into()?;
             if instance == instance1.id {

Removed next() at all. It was only used in render_webxdc_status_update_object() and then indeed better to replace it with saturating_add() there.

Why is this i64 now?

first_serial can be negative now because of the logic in chat::resend_msgs():

"INSERT INTO smtp_status_updates (msg_id, first_serial, last_serial, descr) \
VALUES(?, ?, ?, '') \
ON CONFLICT(msg_id) \
DO UPDATE SET first_serial=min(first_serial - 1, excluded.first_serial)",